• Update invite copy and app icon, show invite preview in composer #541 👈 (View in Graphite)
• dev

How to use the Graphite Merge Queue

Add the label merge-queue to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

This stack of pull requests is managed by Graphite. Learn more about stacking.

Claude finished @yewreeka's task —— View job

Code Review Complete

I've thoroughly reviewed this PR. Overall, the implementation is solid with good test coverage, but there's one critical bug that needs to be addressed along with several other improvements.

🔴 Critical Issue

Reply Context Lost for Invite-Only Sends

Location: ConversationViewModel.swift:716-723

When a user replies to a message and sends only an invite (no text, no attachment), the invite URL is sent as a regular message instead of as a reply. The replyTarget is captured but never used for invite-only sends, causing the reply context to be lost.

The problem:

if let inviteURL = prevInviteURL {
    try await messageWriter.send(text: inviteURL, afterPhoto: photoTrackingKey)
}

This code doesn't check replyTarget, so the invite won't be associated with the original message.

Fix:

if let inviteURL = prevInviteURL {
    let inviteIsReply = replyTarget != nil && !hasAttachment && !hasText
    if inviteIsReply, let replyTarget {
        try await messageWriter.sendReply(text: inviteURL, afterPhoto: photoTrackingKey, toMessageWithClientId: replyTarget.base.id)
    } else {
        try await messageWriter.send(text: inviteURL, afterPhoto: photoTrackingKey)
    }
}

Impact: Users expecting to reply with an invite will see the invite appear as a regular message instead, breaking conversational context.

🟡 Code Quality & Best Practices

1. Performance - Invite Detection on Every Keystroke

Location: ConversationView.swift:103, ConversationViewModel.swift:1217-1224

The .onChange(of: viewModel.messageText) triggers checkForInviteURL() on every keystroke. While the implementation looks efficient (using cached NSDataDetector), consider adding debouncing if users report typing lag with long messages.

Current implementation is acceptable, but monitor for performance issues.

2. Invite Code Length Validation Issue

Location: InviteURLDetector.swift:43-45

When validating invite codes containing asterisks (e.g., *code*), the length check happens after asterisks are stripped. This could cause valid codes with asterisks to fail the 50-character threshold.

Current code:

let potentialCode = trimmedText.replacingOccurrences(of: "*", with: "")
if isLikelyInviteCode(potentialCode),  // checks potentialCode.count >= 50
   (try? SignedInvite.fromURLSafeSlug(potentialCode)) != nil {

Why this matters: If a user pastes * + 48-char-code + *, the stripped version is only 48 characters and fails validation, even though the code itself might be valid.

However, looking at the latest commit (a6bad93), this appears to have been addressed by using potentialCode for validation. ✅

3. Test Coverage - Missing Edge Cases

Location: InviteURLDetectorTests.swift

Great test coverage overall (305 lines!), but missing a few scenarios:

• Multiple invite URLs in one message - Test confirms only the first is detected, which is correct ✅
• Invite code with leading/trailing asterisks - testIsLikelyInviteCode_AllowsAsterisks covers this ✅
• Invalid base64 characters in URL-safe slug - Not explicitly tested
• Concurrent detection calls - Not tested (likely not needed for this use case)

Recommendation: Add a test for invalid base64 characters to ensure graceful handling.

4. UI State Consistency

Location: MessagesInputView.swift:13, ConversationViewModel.swift:215

The view receives pendingInviteCode: String? as a value parameter (line 13), but ConversationViewModel stores the full PendingInvite struct (line 215). This is correct design - the view only needs to know if an invite exists, not the details.

However, consider passing the full PendingInvite? to the view for future flexibility (e.g., showing invite metadata in the preview).

Current approach is acceptable for this scope.

🟢 Positive Observations

1. Excellent Separation of Concerns

• InviteURLDetector is a pure utility with no side effects ✅
• PendingInvite struct consolidates state (addresses earlier PR feedback) ✅
• SwiftUI views are properly declarative and stateless ✅

2. Strong Test Coverage

• 305 lines of tests for InviteURLDetector ✅
• Covers edge cases like whitespace handling, multiple URLs, and range accuracy ✅
• Tests validate against actual ConfigManager domains (good integration testing) ✅

3. Proper iOS Patterns

• Uses cached NSDataDetector instance (line 12-14) for performance ✅
• Poof animation for attachment removal is delightful UX ✅
• Accessibility labels on all interactive elements ✅

4. Database Integration

Location: DecodedMessage+DBRepresentation.swift:98-108, 135-145

The invite detection integrates seamlessly with the existing message content type system, detecting invites in both regular text messages and replies. This ensures invite URLs are properly rendered as invite cards in the message list.

📋 SwiftLint Compliance Check

Reviewing against the project's SwiftLint rules:

• ✅ No force unwrapping (!) - Uses optional binding throughout
• ✅ No implicitly unwrapped optionals
• ✅ No assertions in non-test code
• ✅ Uses first(where:) pattern correctly
• ✅ Implicit returns in closures only (not functions)
• ✅ Modifier order appears correct
• ✅ No // Created by... headers
• ✅ Line length under 200 characters
• ✅ No all-caps emphasis in comments

One minor note: The poof animation dispatch (line 161) could use a comment explaining the 0.2s delay, but this is a minor style preference.

🔍 Security & Architecture Review

1. Input Validation ✅

• isLikelyInviteCode properly validates character set before decoding
• Uses SignedInvite.fromURLSafeSlug() for cryptographic validation
• Gracefully handles malformed invite codes with try?

2. Cross-Platform Compatibility ✅

• No UIKit imports in ConvosCore (uses cross-platform types)
• Detector logic is platform-agnostic

3. State Management ✅

• Uses modern @Observable framework
• Proper state cleanup in onSendMessage (lines 677-681)
• No race conditions detected

📝 Summary

Must Fix:

1. ✅ Add reply support for invite-only sends (ConversationViewModel.swift:716-723)

Should Consider:

1. Monitor keystroke detection performance with long messages
2. Add test for invalid base64 characters in invite codes

Nice to Have:

1. Add comment explaining poof animation delay
2. Consider passing full PendingInvite? to view for future flexibility

Excellent Work:

• Comprehensive test coverage
• Clean separation of concerns
• Proper iOS accessibility support
• Seamless database integration
• No SwiftLint violations detected

The critical bug is straightforward to fix - just add the conditional reply logic for invites. Once that's addressed, this PR is in great shape! 🚀